home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Oct 89 / Z0174-Re File Filter Thou-Oct89 < prev    next >
Encoding:
Text File  |  1989-10-25  |  2.8 KB  |  64 lines  |  [TEXT/GEOL]
  1. Item    0783071                         25-Oct-89        10:09
  2.  
  3. From:   D2086                           Efficient Field Svc, C Faith,PRT
  4.  
  5. To:     NICK                            Kledzik, Nick
  6.         CDA0004                         VAR Shana Enterprises, Don Murphy
  7.  
  8. cc:     MACAPP.TECH$                    MACAPP Tech
  9.  
  10. Sub:    RE File Filter Thoughts
  11.  
  12. Nick and Wayne,
  13.  
  14. Thanks for your replies.
  15.  
  16. I had rather forgotten about the SELF parameter being passed.  I had also not
  17. realized that you can't pass the adress of a method (though perhaps I should
  18. have), and this was in effect what I was really asking.
  19.  
  20. When I read you reply Nick I thought it would be the easier course to define a
  21. global function that would encapsulate the method call (as per Wayne's
  22. suggestion).
  23.  
  24. The reason I wanted to do this is that I am making some big changes to the
  25. MacApp architecture, especially as it concerns TApplication's role.   I have
  26. also made the extensive changes needed to handle TContext and TFile (as
  27. discussed in Jeff Alger's Frameworks article).  I think that currently
  28. TApplication needs to know to much about the role of its Documents(Contexts)
  29. files etc.  You need to OVERRIDE TApplication.SFGetParms to add a Document that
  30. uses a new file type or needs a special file filter.  These decisions belong in
  31. the TContext object.  The application should merely pass the requests along to
  32. each of the TContexts that it can create (not just those that are created).
  33. This holds for finder requests also, TApplication must know what kind of
  34. TContext to create for each file type. TApplication should ask each context in
  35. effect, "Can you open this file?".
  36.  
  37. The fileFilter will simply be an addition of all the fileFilter methods of all
  38. the TContexts that the application can open.  Thus the fileFilter can be
  39. separately specified for the TContext and can move along with it.
  40.  
  41. Even the Open Command handling should be handled by the TContexts,  the
  42. application should ask, "Which of you opens with this Open command?".  With
  43. each TContext having a different Open Command number.  Duplicates could be
  44. detected very easily and an appropriate warning given.
  45.  
  46. At the moment TApplication needs to be changed very frequently when what is
  47. changing is not the behavior of the application but rather its documents.
  48.  
  49. The changes I am making will make it possible to add a new TContext by merely
  50. Using its interface, linking with its code and putting in a linker strip
  51. suppression line ( IF Member(TObject(NIL),TNewContext) THEN;).
  52.  
  53. TApplication will need hardly any changes ever!
  54.  
  55. This type of thing will be very handy for me as I like to code, debug and test
  56. my applications in smaller chunks and then add them all together (without
  57. having to change everything under the sun).
  58.  
  59. It would also be nice to be able to take a TContext from a library and just add
  60. it without any fuss.
  61.  
  62. - Curtis
  63.  
  64.